home *** CD-ROM | disk | FTP | other *** search
/ BBS in a Box 7 / BBS in a Box - Macintosh - Volume VII (BBS in a Box) (January 1993).iso / Files / Tele / M / MacBinary Standard < prev    next >
Text File  |  1988-12-17  |  8KB  |  144 lines
  1.  
  2.  
  3. These are the new changes to the MacBinary Standard, as generally agreed
  4. These are the new changes to the MacBinary Standard, as generally agreed
  5. upon in the MacBinary II Conference 6/21/87, and as changed in the followup
  6. conference 6/28/87.  Revised 7/24/87 to reflect suggestions and clarifications
  7. that came later, and to include all necessary information needed from the
  8. original MacBinary standard document to implement MacBinary II.
  9. The new standard will be very similar to the original MacBinary standard as
  10. described in MACBIN.STD, DL3 of AppDev.  (Reading the original standard is
  11. recommended for a full understanding of implementation and philosophy
  12. behind the MacBinary I and II formats.)  The binary format consists of a
  13. 128-byte header containing all the information necessary to reproduce the
  14. document's directory entry on the receiving Macintosh; followed by the
  15. document's Data Fork (if it has one), padded with nulls to a multiple of
  16. 128 bytes (if necessary); followed by the document's Resource Fork (again, 
  17. padded if necessary). The lengths of these forks (either or both of which
  18. may be zero) are contained in the header.
  19. The format of the header for MacBinary II is as follows:
  20.   Offset 000-Byte, old version number, must be kept at zero for compatibility
  21.   Offset 001-Byte, Length of filename (must be in the range 1-63)
  22.   Offset 002-1 to 63 chars, filename (only "length" bytes are significant).
  23.   Offset 065-Long Word, file type (normally expressed as four characters)
  24.   Offset 069-Long Word, file creator (normally expressed as four characters)
  25.   Offset 073-Byte, original Finder flags
  26.                                  Bit 7 - Locked.
  27.                                  Bit 6 - Invisible.
  28.                                  Bit 5 - Bundle.
  29.                                  Bit 4 - System.
  30.                                  Bit 3 - Bozo.
  31.                                  Bit 2 - Busy.
  32.                                  Bit 1 - Changed.
  33.                                  Bit 0 - Inited.
  34.   Offset 074-Byte, zero fill, must be zero for compatibility
  35.   Offset 075-Word, file's vertical position within its window.
  36.   Offset 077-Word, file's horizontal position within its window.
  37.   Offset 079-Word, file's window or folder ID.
  38.   Offset 081-Byte, "Protected" flag (in low order bit).
  39.   Offset 082-Byte, zero fill, must be zero for compatibility
  40.   Offset 083-Long Word, Data Fork length (bytes, zero if no Data Fork).
  41.   Offset 087-Long Word, Resource Fork length (bytes, zero if no R.F.).
  42.   Offset 091-Long Word, File's creation date
  43.   Offset 095-Long Word, File's "last modified" date.
  44.   Offset 099-Word, length of Get Info comment to be sent after the resource
  45.              fork (if implemented, see below).
  46.  *Offset 101-Byte, Finder Flags, bits 0-7. (Bits 8-15 are already in byte 73)
  47. All Finder flags and information would be uploaded, however, a downloading
  48. program should clear the Finder flag bits of
  49.   0 - Set if file/folder is on the desktop (Finder 5.0 and later)
  50.   1 - bFOwnAppl (used internally)
  51.   8 - Inited (seen by Finder)
  52.   9 - Changed (used internally by Finder)
  53.  10 - Busy (copied from File System busy bit)
  54. Also, fdLocation and fdFldr should be zeroed
  55.  *Offset 116-Long Word, Length of total files when packed files are unpacked.
  56.              This is only used by programs that pack and unpack on the fly,
  57.              mimicing a standalone utility such as PackIt.  A program that is
  58.              uploading a single file must zero this location when sending a
  59.              file.  Programs that do not unpack/uncompress files when
  60.              downloading may ignore this value.
  61.  *Offset 120-Word, Length of a secondary header.  If this is non-zero,
  62.              Skip this many bytes (rounded up to the next multiple of 128)
  63.              This is for future expansion only, when sending files with
  64.              MacBinary, this word should be zero.
  65.  *Offset 122-Byte, Version number of Macbinary II that the uploading program
  66.              is written for (the version begins at 129)
  67.  *Offset 123-Byte, Minimum MacBinary II version needed to read this file
  68.              (start this value at 129 129)
  69.  *Offset 124-Word, CRC of previous 124 bytes
  70.  *This is newly defined for MacBinary II.
  71. All values are stored in normal 68000 order, with Most Significant Byte
  72. appearing first then the file.  Any bytes in the header not defined above
  73. should be set to zero.
  74. The original MacBinary format was ammended to include the sending of the FCMT
  75. (Get Info comment) after the resource fork was sent, if the length for such
  76. comment, given in offset 99, is not zero.  To the best of our knowledge, no
  77. program has implemented this feature, due to Apple's stated position that no
  78. program should read or write these comments.  The definition remains in
  79. MacBinary II, so that should Apple ever provide a documented way of reading and
  80. writing these comments, terminal programs will be able to take advantage of
  81. this feature. 
  82. All Finder flags and information would be uploaded, however, a downloading
  83. program should clear the Finder flag bits of
  84.   0 - Set if file/folder is on the desktop (Finder 5.0 and later)
  85.   1 - bFOwnAppl (used internally)
  86.   8 - Inited (seen by Finder)
  87.   9 - Changed (used internally by Finder)
  88.  10 - Busy (copied from File System busy bit)
  89. Also, fdLocation and fdFldr should be zeroed
  90. To determine if a header is a valid  MacBinary header, check bytes 0 and 74 to
  91. be both zero.  If they are both zero, either (a) the CRC should match, which
  92. means it is a MB II file, or (b) byte 82 is zero, which means it may be a MB I
  93. file.  (Note that, at the current version level, byte 82 is kept zero to
  94. maintain compatibility with MacBinary I. If at some point the MacBinary
  95. versions change sufficiently that it is necessary to keep MacBinary I programs
  96. from downloading these files, we can change byte 82 to non-zero.)
  97. If the header is a MB II header, the program will check the minimum version
  98. byte, to see if it knows enough to decode the file.  If the minimum version in
  99. the header is greater than the version that the terminal program was written
  100. for, it will download the file as pure XModem (creating a "TEXT" file) and
  101. notify the user that conversion is needed because the MacBinary version was too
  102. high.
  103. If the header does NOT represent a valid MB II header, the program must at
  104. minimum check byte 82 to be zero--if it is not zero, the file is not a MB I
  105. file.  It is possible to write a much more robust routine, by checking the
  106. following:
  107.   Offsets 101-125, Byte, should all be 0.
  108.   Offset 2, Byte, (the length of the file name) should be in the range of 1-63.
  109.   Offsets 83 and 87, Long Word, (the length of the forks) should be in the
  110.     range of 0-$007F FFFF.
  111. If any of these tests fail, the file is not a valid MacBinary file.  It may
  112. still be desirable to distinguish between text files and foreign binary files
  113. (for stripping line feeds or similar helpful acts).  Some tests that would
  114. prove useful include:
  115.    A quantity of bytes in the first block with the high bit set would point to
  116.      a binary file (though this could be fooled by files with many extended
  117.      ascii characters, such as generated by the option key on a Mac).
  118.    A large quantity of zero bytes (nulls) would also point to a binary file.
  119. ------------------------------------------------------------------------
  120.  This proposal was adopted at two conferences attended by representatives from
  121. CompuServe, Delphi and BIX networks, and many terminal software publishers.  A
  122. partial list of those participating is:
  123.     Peter Olson/ICONtac
  124.     Larry Loeb/BIX
  125.     Neil Shapiro/Maug
  126.     Mark Hagerman
  127.     Michael Pester
  128.     William Bond
  129.     Bill Steinberg
  130.     Don Brown
  131.     Bill Davis
  132.     Jean Hess
  133.     Scott Watson
  134.     Clay Maeckel
  135.     Harry Chesley
  136.     Jack Brindle
  137.     Raines/BMUG
  138.     Harry Conover
  139.     Chris Allen/Dreams of the Phoenix
  140.  
  141. Download complete.  Turn off Capture File.
  142.  
  143.  
  144. Download another file (Y/N)?